home *** CD-ROM | disk | FTP | other *** search
/ Amiga News 95 / Amiga News 95.iso / picjuin / xrn.16c (.png) < prev   
IFF Interleaved Bitmap Image  |  1995-05-08  |  65KB  |  512x831  |  4-bit (11 colors)
Labels: text | screenshot | font | document | black and white | number
OCR: xn - version 7.01-beta-5 + 86 XtCallActionProc adequate? [70] Jan Newmarch u 87 RAP security [29] Jan Newmarch 88 RAP protocol count [86] Jan Newmarch Operations apply to current selection or cursor position Quit Catch up Fed up Goto article Mark read Unsubscribe Subject next Subject prev Suchen Thema Post From: jan@pandonia. canberra. edu, au (Jan Newmarch) Subject: XtCallActionProc adequate? I thought a question was raised in passing about the adequacy of XtCallActionProc for controlling Xt applications but I couldn't track down the reference, Based on my experience with replayXt, here are some comments on this. There is an immediate failure of XtCallActionProc, and that is if an application is using low-level event handlers as registered by XtAddEventHandler, My reading of Asente & Swick is that it is expected that most uses of this will be from widget writers rather than application writers, but it is also used by things like editres. However it is used, the event handlers are not accessible by XtCallActionProc and they can only be invoked by constructing a suitable X event and injecting it into the queue. The major interface of a widget with its environment is by widget actions, and these are accessible by XtCallActionProc. This interaction is in fact one stage removed from the user actions such as button presses, because the user actions are put through the translation table first to find the corresponding action. I do not find this a problem as you want to control the widget's behaviour and not have the RAP suffer from the vagaries of user-set translation tables. Otherwise you would have to go through a tedious session of establishing just what the translation table was for each widget. However, XtCallActionProc takes as parameter an X event, and in real life this will be the X event that triggered the action, This is where XtCallActionProc seriously breaks down, in that there is no requirement to specify or document what use is made by the widget of this event. The semantics of the function are clear, but what the action will actually do is not. A simple example: the Motif PushButton calls the action Arm() when the left button is pressed (default translations) and Activate() when it is released. Both of these assume that the event type is a ButtonPress when the translation table settings may in fact have changed this. The reason for this assumption is that on release, the widget checks to see if Art. 86 in sophia, listes, x-agent (2 left) (Next; rec. games. net Save Reply Forward Followup Followup & Reply Cancel Rot-13 Translate Toggle header Print